-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add validateToken method to auth client #10
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #10 +/- ##
============================================
- Coverage 96.25% 95.58% -0.67%
- Complexity 71 77 +6
============================================
Files 5 5
Lines 187 204 +17
Branches 37 39 +2
============================================
+ Hits 180 195 +15
- Misses 5 7 +2
Partials 2 2 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me, as long as those test tokens are immortal.
KBASE_CI_TOKEN2: ${{ secrets.KBASE_CI_TOKEN2 }} | ||
run: | | ||
cp test.cfg.example test.cfg | ||
sed -i "s#^auth_token1 =.*#auth_token1 = $KBASE_CI_TOKEN#" test.cfg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You test stuff live? Do these tokens expire? You might want to make a calendar event to update once in a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're managed by devops and last for 100 years
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some point I want to stand up the auth server in testmode rather than use tokens, but... later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how the old tests ran so I didn't want to change too much
sed -i "s#^auth_token1 =.*#auth_token1 = $KBASE_CI_TOKEN#" test.cfg | ||
sed -i "s#^auth_token2 =.*#auth_token2 = $KBASE_CI_TOKEN2#" test.cfg | ||
sed -i "s#^auth_user1 =.*#auth_user1 = kbase_bot#" test.cfg | ||
sed -i "s#^auth_user2 =.*#auth_user2 = sychan168#" test.cfg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and maybe make a new user here... :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah. :/ I mentioned it to devops
if (t != null) { | ||
return t; | ||
} | ||
final URI target = rootURI.resolve("api/V2/token"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to setRequestMethod here when calling target url?
api/v2/token could be either a GET or POST based on auth2 doc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a GET by default and the method we want to use for both tokens, and later users, are GETs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
No description provided.